Real-Time Operating Systems: Pros, Cons and Uses

Abstract

There have been many things written about Real Time Operating Systems, describing, its differences from commonly known Operating systems, its functionality, its purpose, its constraints, the markets it operates within and the products it supplies within these markets. In this article I aim to highlight significant interpretations of Real Time Operating Systems.

Introduction to Real-Time Operating Systems

Before talking about Real-Time Operating Systems it is important to know what an Operating System is. According to Beal (n.d.) an Operating System is the most important program that runs on electronic devices. Operating Systems are used to perform basic tasks on electronic devices, which include recognizing keystrokes on a keyboard, displaying data on a screen, keeping track of files and their directories (Beal, n.d.).

Examples of Devices and their Operating Systems are listed below:

• Personal computer operating systems = Microsoft Windows, Mac OS X, Linux
• Apple Mobile phone operating system = iPhone OS
• Mobile phone operating systems = Android, Blackberry, Nokia’s Symbian, Web OS, Microsoft Windows
• Tablets & Laptops operating system = Microsoft Windows, MacOS X, Apple iOS, Google, HP, Blackberry

Beal (n.d.) describes an Operating System as a Traffic cop as she states “It is like a traffic cop — it makes sure that different programs and users running at the same time do not interfere with each other.” Operating Systems are responsible for security as they ensure that any unauthorised users cannot access the system (Beal, n.d.).

According to Beal (n.d.) an Operating System provides a software platform where other programs, called Application Programs run on top. There are a number of different types of Operating Systems, they include:

• Multi-user
• Multiprocessing
• Multitasking
• Multithreading
• Real-Time (Beal, n.d.)

The type of Operating that I will be focusing on in this essay will be Real-Time Operating Systems.

What is a Real-Time Operating System?

High Integrity Systems (n.d.) describes a Real-Time Operating System (Commonly Known as an RTOS) as a software component that rapidly switches between individual programing threads (also known as: tasks), giving the user the impression that there are multiple programs being executed simultaneously on a Central Processing Unit (CPU), as a CPU can only execute one task at any one time (High Integrity Systems, n.d.).

Ni.com (2013) likens a Real-Time Operating System to a general Operating Systems in that they are responsible for managing the hardware resources of a computer and for hosting all applications that run on a computer. NI.com (2013) goes on to describe a Real-Time Operating System as being specifically designed to run computer applications with very precise timing and a high degree of reliability, as this is very important in measurement of system automation. Downtime is very costly and a delay in a program could cause a safety and security issues (High Integrity Systems, n.d.).

Thakur (n.d.) characterises a Real Time Operating System as an environment where a large number events must be accepted and processed in a very short period of time. Programs within a system get swapped between primary and secondary memory, with memory management being less demanding when compared to other systems, this being due to processes remaining mainly in the primary memory in order to provide the fastest possible responses (Thakur, n.d.).

Thakur (n.d.) defines the primary functions of a Real Time Operating System as:

• Managing the processor and other system resources in order to meet the requirements of applications
• Synchronizing with and responding to system events
• Moving data efficiently among processes and performing coordination among these processes (Thakur, n.d.)

Along with the above listed primary functions Thakur (n.d.) advises that a Real-Time Operating System has Secondary functions.  They, listed below, are not mandatory but are included to enhance the performance:

• To provide an efficient management of ram
• To provide an exclusive access to the computer resources (Thakur, n.d.)

In simple terms a Real Time Operating System could be described as very fast responsive operating system, reacting simultaneously too many demands/commands whilst ensuring its integrity.

Do I Need a Real-Time Operating System?

Yes, and below are listed seven reasons why:

• Concurrency
• Pre-emption
• Available Ram
• Available Flash
• Synchronization Tools
• Third-Party Software
• Ease of Use (Design News, 2016)

Concurrency

In applications where tasks need to appear to be executing at the same time or concurrently, the use of a Real Time Operating System makes sense (Design News, 2016). A Real Time Operating System can have multiple tasks simultaneously in memory and can switch between them based on events and priorities (Design News, 2016).

Pre-emption

Pre-emption is the ability of an operating system to temporarily suspend a task in order to execute another higher-priority task (Design News, 2016). The nature of most Real Time Operating System systems is to determine which tasks should be executing at any given time, based on the priority of the task and system conditions (Design News, 2016). If the embedded software that is being developed requires the need to prioritize and interrupt tasks that are currently running, a Real Time Operating System is the go-to operating system (Design News, 2016).

Available Ram

The amount of available RAM on a microcontroller can be a big determining factor as to whether a Real Time Operating System can or cannot be used (Design News, 2016). Resource-Constrained systems with less than 4 kilobytes of RAM would have difficulty operating within this memory capacity due to the fact that each task has its own control block and stack (Design News, 2016). As a result of this it is recommended that a microcontroller based system should have at least 4 kilobytes of RAM before going for a Real-Time Operating System solution, ideally a minimum system requirement of 8 kilobytes is preferred (Design News, 2016).

Available Flash

Since a developer should look at how much RAM is available on a system before deciding to go with a Real Time Operating System, they should also look at how much Flash space is available (Design News, 2016). Real Time Operating System systems don’t take up much Flash space, usually on the order of eight to 10 kilobytes, but if the microcontroller only has 16 kilobyte of Flash space, there really isn’t much room left for the application code (Design News, 2016). Ideally a microcontroller should have at least 32 kilobytes of Flash space as this will make the system a good candidate for the use of a Real Time Operating System (Design News, 2016). Anything less and it might be time to upgrade the hardware (Design News, 2016).

Synchronization Tools

A Real-Time Operating System has Mutexes that can be used to protect shared resources (Design News, 2016). It also contains Semaphores that can be used to signal and synchronize tasks and message queues to transfer data between tasks (Design News, 2016). Properly designing and implementing these core software features isn’t trivial, If a system has multiple tasks and protected resources that require synchronization, then the use of a Real Time Operating System is the wise decision (Design News, 2016).

Third-Party Software

One of the problems facing developers worldwide today is how to integrate third-party software stacks and tools into their embedded system (Design News, 2016). Third-party stacks and tools that are available today on the market are compatible with various Real Time Operating System’s (Design News, 2016). The use of a Real Time Operating System makes these components plug-and-play within the software and can dramatically accelerate software development (Design News, 2016). The decision to use third-party software could be a major indicator that a Real Time Operating System should be used (Design News, 2016).

Ease of Use

Real Time Operating System systems are readily available for nearly every microcontroller and for nearly every application imaginable (Design News, 2016). Whether a developer just wants to create a rapid prototype or build a robust safety-critical system, a Real Time Operating System exists so that developers can leverage and get up and running fairly quickly (Design News, 2016). Creating tasks and utilizing Real Time Operating System tools is easy and very powerful, but developers need to ensure they properly analyze their tasks and think through their system design (Design News, 2016). A Real Time Operating System is a powerful tool, but improper use can result in tragedy (Design News, 2016).

Advantages of Real-Time Operating Systems

High Integrity Systems (n.d.) state there are a number of advantages to using a Real Time Operating System, which are listed and described below:

• Priority Based Scheduling
• Abstracting Timing Information
• Maintainability/Extensibility
• Modularity
• Promotes Team Development
• Easier Testing
• Code Reuse
• Improved Efficiency
• Idle Processing (High Integrity Systems, n.d.)

Priority Based Scheduling

Priority Based Scheduling refers to a part in a Real Time Operating System called The Scheduler (Freertos.org, n.d.). The scheduler is responsible for deciding which task should be executing at any particular time (Freertos.org, n.d.). In general a Real Time Operating System has the ability to suspend and resume at a later time tasks infinitely throughout a tasks lifetime (Freertos.org, n.d.).

The scheduler uses an algorithm to help it decide which task it should execute at any point in time called the Scheduling Policy (Freertos.org, n.d.). Even though a Real Time Operating System has the ability to suspend tasks before they are complete, tasks also have the ability to suspend themselves at any time (Freertos.org, n.d.). Tasks can suspend themselves when they want to delay (sleep) themselves for a fixed period of time, or wait (block) for a resource to become available for example: a serial port or an event to occur such a key press on a keyboard (Freertos.org, n.d.). Tasks that are sleeping or blocked are not able to execute and thus they will not be allocated any processing time (Freertos.org, n.d.).

Abstracting Timing Information

As described in the previous Real Time Operating System advantage, a Real Time Operating System is responsible for timing and providing Application Programming Interface (API) functions (Freertos.org, n.d.).

According to Techterms.com (n.d.) an API is a set of commands, functions, protocols and objects that can be used by programmers to create software or interact with an external system. An API provides Developers with a set of standard commands which can be used to perform a number of common operations, thus removing the need for them to write code from scratch (Techterms.com, n.d.). This is a big advantage for Real Time Operating System as it allows Developers to write smaller and neater application code (Techterms.com, n.d.).

Maintainability/Extensibility

The Real Time Operating Systems ability to abstract timing dependences and incorporate task based design results in their being fewer interdependencies between modules as well as making maintenance easier (High Integrity Systems, n.d.).

Modularity

A Real Time Operating System is a modular operating system which separates the core kernel from middleware, protocols and applications (Micrium.com, n.d.). This eases development and reduces the memory footprint of the Real Time Operating System on the system (Micrium.com, n.d.).

The modularity of a Real Time Operating System simplifies a Developers development process (Micrium.com, n.d.). This is important for developers when they are developing for devices with different capabilities such as Desktop computers (Micrium.com, n.d.). Relying a common core allows an entire family of devices to share a common base code (Micrium.com, n.d.). The modularity of a Real Time Operating System allows for the embedded software to be tailored to specific devices, which reduces the RAM and Flash memory (Micrium.com, n.d.).

Promotes Team Development

The task based system provided by Real Time Operating System allows for separate designers/teams to work independently on their parts of a project (High Integrity Systems, n.d.).

Easier Testing

The modular task-based development that a Real Time Operating System provides allows for modular task based testing (High Integrity Systems, n.d.).

Code Reuse

A benefit that a modular Real Time Operating System provides is that similar applications on similar platforms will lead to the development of a library of standard tasks (High Integrity Systems, n.d.).

Improved Efficiency

A Real Time Operating System can be entirely event driven; no processing time is wasted polling for events that have not occurred (High Integrity Systems, n.d.)

Idle Processing

Background or idle processing is performed in the idle task (High Integrity Systems, n.d.). This ensures that things such as CPU load measurement, background CRC checking etc will not affect the main processing (High Integrity Systems, n.d.).

Disadvantages of Real-Time Operating Systems

There are various reports written about the Disadvantages of Real-Time Operating Systems, the most common of which include:

• Limited Tasks
• Use Heavy System resources
• Complex Algorithms
• Device driver and interrupt signals
• Thread Priority (GeeksforGeeks, n.d.)

Limited Tasks

Very few tasks run at the same time and their concentration is restricted to few applications to avoid errors (GeeksforGeeks, n.d.).

Use Heavy System resources

Sometimes the system resources are not efficient and can be quite expensive (GeeksforGeeks, n.d.).

Complex Algorithms

The Algorithms are very complex and can create difficulties for developers when trying to edit the Algorithm (GeeksforGeeks, n.d.).

Device driver and interrupt signals

It needs specific device drivers and interrupt signals in order for it to respond to interrupts at its earliest opportunity (GeeksforGeeks, n.d.).

Thread Priority

It is not good to set thread priority as these systems are less prone to switching tasks (GeeksforGeeks, n.d.).

How do RTOSs differ from General Purpose Operating Systems?

With the Internet of Things, Real Time Operating System’s have been gaining in popularity lately (Arthur, 2017). Real-Time Operating Systems are much better-suited for use in embedded systems than General Purpose Operating System’s, and more efficient in many cases (Arthur, 2017).

Common General Purpose Operating Systems include platforms such as Linux, Windows and Mac OS, it is an essential component of any mobile device, server, or computer system (Arthur, 2017). A General Purpose Operating System is responsible for running all the applications in an installation (Arthur, 2017). However, it’s not really made for real-time use; that’s where Real Time Operating System’s come in (Arthur, 2017).

Real-Time Operating Systems are designed for use cases in where time is of the essence, for example: in connected cars (Arthur, 2017). Processing time must be significantly shorter than in a General Purpose Operating System, and the execution pattern for applications and processes needs to be predictable (Arthur, 2017). Generally, they also run on smaller, more lightweight hardware than General Purpose Operating System’s, as larger hardware configurations tend to have issues with agility (Arthur, 2017).

They differ in a number of ways:

• A Real Time Operating System always works on priority-based scheduling, whereas a General Purpose Operating System task scheduling is not always based on which application or process has priority (Arthur, 2017).
  • A Real Time Operating System is used for time critical systems (Arthur, 2017).For Example: VxWorks, uCos (Arthur, 2017). It can also be said that a Real Time Operating System is supposed to give a quick and predictable response (Arthur, 2017).
• The greater the number of threads that are running in a General Purpose Operating System, the longer it will take to schedule and start executing a thread (Arthur, 2017).
• In a General Purpose Operating System, a high-priority thread cannot pre-empt a kernel call (Arthur, 2017). In a Real Time Operating System, a low-priority task will be pre-empted by a high-priority one if necessary, even if it’s executing a kernel call (Arthur, 2017).
• Where development is concerned, a General Purpose Operating Systems code generally isn’t modular in nature, whereas a Real-Time Operating Systems Kernel Code is designed to be scalable, so that developers can pick and choose Kernel objects selectively (Arthur, 2017).

Components, Characteristics and Design Requirements of Real-Time Operating System

Components

There are a number of components that make up a Real-Time Operating System, they include:

• The Scheduler
• Communication Mechanism
• Critical Region Mechanisms
• Timing Services
• Power Management
• Memory Management
• Peripheral Drivers
• Protocol Stacks
• File System
• Device Management (Dev.ti.com, n.d.)

The Scheduler

The Scheduler schedules different processes which are to be assigned to a CPU based on particular scheduling algorithms (www.tutorialspoint.com, n.d.). There are a number of different scheduling algorithms that can be used by the Scheduler, according to www.tutorialspoint.com (n.d.) the six most popular scheduling algorithms are:

• First-Come, First-Served (FCFS)
• Shortest-Job-Next (SJN)
• Priority Scheduling
• Shortest Remaining Time
• Round Robin (RR)
• Multiple-Level Queues (www.tutorialspoint.com, n.d.)

The above listed algorithms are either Non-Preemptive or Pre-emptive (www.tutorialspoint.com, n.d.). A Non-Pre-emptive algorithm is designed in such a way that once a process enters the running state, it can’t be pre-empted until it completes its allotted time (www.tutorialspoint.com, n.d.). A Pre-emptive algorithm’s scheduling is based on priority, this is where the scheduler may pre-empt a low priority running process at anytime when a high priority process enters the ready state (www.tutorialspoint.com, n.d.).

A Real Time Operating System can use Non-Pre-emptive and Pre-emptive, however Pre-emptive Schedulers are the most common (Dev.ti.com, n.d.).

Communication Mechanism

All Real-Time Operating Systems offer a standard communication mechanism (Dev.ti.com, n.d.). A few Communication mechanisms include:

• Semaphore
  • Semaphore is a signal between tasks that does not carry any additional data (Percepio AB, 2016). The meaning of a signal is implied by a semaphore object, thus one semaphore is needed per purpose (Percepio AB, 2016). The most common type of semaphore used by Real-Time Operating Systems is a Binary Semaphore that triggers activation of a task (Percepio AB, 2016). The typical design pattern is that a task contains a main loop with a Real-Time Operating System call to “take” the semaphore (Percepio AB, 2016). If a semaphore has not been signalled, the Real-Time Operating System blocks the task from executing any further until some task or interrupt signals the semaphore (Percepio AB, 2016).
• Binary
  • A Binary semaphore is a semaphore which only takes 0 and 1 as its values (Sawaal.com, n.d.). A Binary semaphore is used to implement mutual exclusion and synchronize concurrent processes (Sawaal.com, n.d.).
• Mutex
  • Mutex is a binary semaphore for mutual exclusion between tasks, to protect a critical section (Percepio AB, 2016). Internally a Mutex semaphore works in a similar way to a binary semaphore, however it is used in a different way (Percepio AB, 2016). A mutex typically stores the current task and sometimes may boost its scheduling priority to avoid priority inversion (Percepio AB, 2016).

Priority inversion is where a higher priority task is accidentally delayed by a lower priority task, this is normally not possible in a Real-Time Operating System using Fixed Priority Scheduling (Percepio AB, 2016).

Critical Region Mechanisms

Critical Region Mechanisms include the following:

• Mutexes – A mutex (mutual exclusion object) is a program object that is created so that multiple program threads can take turns sharing the same resource, such as accessing a file (Rouse, 2005). When a program is started, it creates a mutex for a given resource at the beginning by requesting it from the system, the system then returns a unique ID for it (Rouse, 2005).  After that, any thread needing the resource must use the mutex to lock the resource from other threads while it is accessing the resource (Rouse, 2005). If the mutex is already locked, a thread needing the resource is queued by the system and then given control when the mutex becomes unlocked (when once more, the mutex is locked during the new thread’s use of the resource) (Rouse, 2005).
• Gates – More commonly known as logic gates, are elementary building block of a digital circuit (Rouse, 2018). Most logic gates have two inputs and one output (Rouse, 2018). At any given moment, a logic gate is in one of the two binary conditions low (0) or high (1) represented by different voltage levels (Rouse, 2018). The state of a logic gate can change often, as the circuit processes data (Rouse, 2018). In most logic gates, the low state is approximately zero volts (0 V), while the high state is approximately five volts positive (+5 V) (Rouse, 2018).
• Locks – A lock is a mechanism used to synchronize different processing threads, with set limits to avoid unlimited accessibility of a certain resource within a computing environment (Techopedia.com, n.d.). It is a method meant to arrange access by applying simultaneous control policies (Techopedia.com, n.d.). Locks are typically advisory, which means that a thread works collaboratively with other threads to acquire the lock before it is given accessibility to the data it queries (Techopedia.com, n.d.). Mandatory locks are also applied by some systems, where an exception occurs as a result of unauthorized access to a source in a locked status (Techopedia.com, n.d.).

Timing Services

This is where internal clocks and timers are used to measure how long a task has been processing for and to restrict task processing time in order to allow for fair usage of the processor by all tasks.

Power Management

A Real-Time Operating System is able to keep itself working efficiently within the power limitations of a device as it is aware of the power usage rate and battery level.

Memory Management

Memory management is the process by which a computer control system allocates a limited amount of physical memory among its various tasks in a way that optimizes performance (electric equipment, 2016). Each task has its own private address space, initially divided into three logical segments: text, data, and stack (electric equipment, 2016). The text segment is read-only and contains the machine instructions of a program, whilst the data and stack segments are both readable and writable (electric equipment, 2016). The data segment contains both initialized and non-initialized data portions of a program, whereas the stack segment holds the application’s run-time stack (electric equipment, 2016). On most machines, this is extended automatically by the kernel as the task executes (electric equipment, 2016). This is done by making a system call, but change to the size of a text segment only happens when its contents are overlaid with data from the file system, or when debugging takes place (electric equipment, 2016). The initial contents of the segments of a child process are duplicates of the segments of its parent (electric equipment, 2016).

Peripheral Drivers

This includes the drivers that run both internal and external devices on the system such as: the graphics card, hard drives, keyboards, mouse, monitor etc.

Protocol Stacks

This includes protocols that allow users to do interact with internal programs and connected devices, such as: file transfer, gameplay, print, access the internet etc.

File System

Each Real-Time Operating System has a set configuration of how it retains different file types.

Device Management

Due to the speed of a Real-Time Operating System it is able to communicate with multiple devices simultaneously and efficiently, handling both internal and external errors.

Characteristics and Design requirements

Listed below are Characteristics and Design requirements of a Real-Time Operating System:

• Real-Time Computing
• Hard Real-Time and Soft Real-Time
• Aperiodic and Periodic tasks
• Determinism
• Responsiveness
• User control
• Reliability
• Fail-Soft operation
• Real-Time scheduling
• Design philosophies
• Memory allocation

Real-Time Computing

According to Techopedia (n.d.), Real-time computing (RTC) is a term for computing practices that have specific time constraints. Real-time computing has to be done in a time frame that is relatively imperceptible to the user (Techopedia.com, n.d.). By contrast, other types of computing can be done on a delayed basis, for instance, where information is aggregated, kept and stored for later use (Techopedia.com, n.d.).

Hard Real-Time and Soft Real-Time

Hard Real-Time Operating System is a type of Operating System where we can predict the deadline, Hard Real-Time systems are constrained to predicted time constraints, deadlines and latency (Jcsites.juniata.edu, 2017).

Whereas a Soft Real-Time Operating System is a type of Operating System where certain deadlines may be missed, Soft Real-Time systems are not constrained to extreme rules (Jcsites.juniata.edu, 2017). The critical time of the Soft Real-Time systems may be delayed to some extent (Jcsites.juniata.edu, 2017). The expected latency between the tasks and time constraints may be deviated (Jcsites.juniata.edu, 2017).

Aperiodic and Periodic tasks

Aperiodic task is a process that has a constraint on the start or the stop time. Whereas a Periodic task is a process that has to carry out its task in regular time intervals.

Determinism

Determinism dictates how an Operating System performs operations at fixed, predetermined times or time intervals.

Responsiveness

This is the time that an Operating System takes to respond once acknowledgement of the interrupt has taken place.

User control

User control can influence the scheduling of the tasks.

Reliability

Robust Operating Systems, both software and hardware needed more than ever today.

Fail-Soft operation

The Operating System requires the ability to recover from failure with little or no loss of capability and data.

Real-Time scheduling

For many Real-Time systems, the work-load changes from moment to moment, based on external events. These require dynamic scheduling.

Design philosophies

Some of the design philosophies of a Real-Time Operating Systems are with respect to:

• Scheduling
• Memory allocation
• Inter task communication
• Interrupt handlers (B and profile, 2014)

Memory allocation

The Real-Time Operating System kernel needs RAM each time a task, queue, mutex, software timer, semaphore or event group is created (Freertos.org, n.d.). The RAM can be automatically dynamically allocated from the Real-Time Operating System heap within the Real-Time Operating System API object creation functions, or it can be provided by the application writer (Freertos.org, n.d.).

Comparative assessment of commercially available Real-Time Operating Systems applications

General Statement

Real time is a more flexible word. Sometimes a very small delay is added and sometime because of the network some delay can happen, but anything that can react quickly/instantly can be considered to be happening in real time.

Basic Real Time Operating Systems

Basic Calculators to Large screen Calculators which can display larger results. It can be said that this technology has progressed, from personal use to business use with the creation of Electronic Cash Registers and Point of Sale systems. Each system increasing its internal Hard and Random memory but with the emphasis on producing results instantly from the keystroke commands made.

Some would argue that these basic calculators were the foundation to modern day computers, the applications that connect to them and software programmes that operate within them. Some of the software incorporated with modern day computers can be described as Real Time Operating Systems in that peripherals are plug and play and that they are instantly recognised by the system and operational very quickly.

Printers & All-In-One Devices are examples of these plug and play peripherals that can be linked to a computer, but these can also be operated independently too because of both Hard and Random memory being incorporated within them .

Sewing Systems, working with you to your preset commands because they too have Hard and Random memory within them. These can also be expanded into modern day clothing and household decor industries, as can printers, to mass manufacture products for the consumer market. A Real Time Manufacturing Operating System.

Video Doorbell, reporting direct to you via mobile device, in real time and you don’t even have to be at home to respond. Again another device that operates independently, with pre programmed software that interacts with your devices once set up, sending you live images of anyone approaching your property. A Real Time Security Operating System.

Heart pacemakers. These devices are inserted into the human body, which again, pre programmed react to changes in the patient heart beat, taking corrective action as necessary to ensure the individual remains in good health. A Real Time Health Operating System.

More Advanced Real Time Operating Systems

A Motor Vehicle will incorporate more than one Real Time Operating System within its manufacturing and built product (Walls, 2016). Looking at the completed product, for instance a family car (Walls, 2016). Within its build it has potential to incorporate various types of Real Time Operating Systems. Some operating independently, whilst others working together (Walls, 2016):

• Engine Faults reported in Real Time to the Vehicle display panel.
• Service reminders built into the system and reporting also in Real Time to the display panel.
• Tyre pressure sensors operating, once set, with again a display on the panel.
• Fuel levels displaying in Real Time on the display panel.
• Parking sensors and/or a camera linked to a display unit giving either a visual or sound warning of proximity to hazards in Real Time.
• Climate controls, which can be changed instantly, in Real Time, by the occupants changing the settings on a control panel. (Walls, 2016)

These are just some of the Real Time Operating Systems that can be built into family cars (Walls, 2016). Providing Real Time Health and Safety checks of the vehicle ensuring the commuters safety and comfort needs are met (Walls, 2016).

From an embedded software engineer’s point of view, a car has become a mobile box full of embedded systems (Walls, 2016).

Modern cars have dozens of microprocessors and microcontrollers, which span the complete spectrum of power/complexity from tiny 4-bit controllers to monster 32-bit (maybe 64-bit) supercomputers on a chip (Walls, 2016). Every system is electronic and a variety of design approaches are applicable (Walls, 2016).

Just about every new development in cars today has its roots in electronics, mostly embedded systems which means that software is a critical issue (Walls, 2016). Some of the standards that apply to electronic systems in cars (not an exhaustive list) (Walls, 2016):

• CAN Bus – a means to reliably connect numerous systems together whilst minimizing the amount of wiring.
• MISRA C (and C++) – a detailed set of guidelines in the use of this language in a safety critical system, like a car.
• OSEK/VDX – a standard for real time operating systems used in such systems in cars.
• Genivi – a standard for Linux based systems used for in-car infotainment systems. (Walls, 2016)

In the Medical sector keyhole surgery also use a combination of Real Time Operating Systems to complete operations on patients. One such system which was being developed in 2016 and reported on at the time is detailed and described below:

Development of a Real-time Operating System Based Control System for Laparoscopic Surgery Robot in the Health Sector

This Real Time Operating System is based on a master-slave configuration robot control system for a laparoscopic surgery robot which enables telesurgery and overcomes shortcomings with conventional laparoscopic surgery (Research Gate, 2008). Surgery robot system requires control system that can process large volume information such as medical image data and video signal from endoscope in a Real-Time manner, as well as precisely control the robot with high reliability (Research Gate, 2008). To meet the complex requirements, the use of high-level Real-Time Operating System in surgery robot controller is a must, which is as common as in many of modem robot controllers that adopt Real-Time Operating System as a base system software on which specific functional modules are implemented for more reliable and stable system (Research Gate, 2008). The control system consists of joint controllers, host controllers, and user interface units (Research Gate, 2008).

Each master, slave and Gill (Graphical User Interface) host runs a dedicated Real-Time Operating System, RTLinux-Pro (FSMLabs Inc., U.S.A.) on which functional modules such as motion control, communication, video signal integration and etc, are implemented, and all the hosts are in a gigabit Ethernet network for inter-host communication (Research Gate, 2008). Each master and slave controller set has a dedicated CAN (Controller Area Network) channel for control and monitoring signal communication with the joint controllers (Research Gate, 2008). Total 4 pairs of the master/slave manipulators as current are controlled by one host controller. The system showed satisfactory performance in both position control precision and master-slave motion synchronization in both bench test and animal experiment, and is now under further development for better safety and control fidelity for clinically applicable prototype (Research Gate, 2008).

Real Time Operating System applications for the Financial Sector

R3 Aims to Build the ‘Operating System of Finance’ (Vitáris, 2017). The CEO of R3, David Rutter, has stated that his company seeks to build the “operating system of finance” and compared their project to a platform like Apple’s App Store (Vitáris, 2017).

R3 (or R3CEV) is a distributed database company headquartered in New York City (Vitáris, 2017). The firm leads a consortium aimed at the development of blockchain database usage in the financial system (Vitáris, 2017). Their plan is to unify the banking system by one ledger, which would allow the validation of transactions in near-real time (Vitáris, 2017). The company created a blockchain-based platform called “Corda“, which can be used by developers to build applications for financial institutes (Vitáris, 2017). Just as Microsoft developed the Windows operating system to run various software, R3 seeks to do the same with Corda (Vitáris, 2017).

David Rutter said “Corda is a completely open system that is going to empower entrepreneurs to be able to build Corda apps, roll them out, and actually have them be adopted because they will work with the current financial rails, in a way that is cognizant (having knowledge or awareness) of and compliant with the regulatory regimes” (Vitáris, 2017).

In an interview with Business Insider,  Rutter said banks are spending tens of billions of dollars each year on writing APIs (Application programming interface) between trading and order management systems (Vitáris, 2017). The CEO stated that such third party software “doesn’t communicate easily” (Vitáris, 2017). Santander’s 2015 report backs Rutter’s statement, where researchers of the financial institute reported that the blockchain technology could save banks as much as $20 billion per year (Vitáris, 2017).

Conclusion

Real-Time Operating System are becoming more common place platforms for use across all walks of life both at home and commercially. When making the a decision about adopting a Real-Time Operating System you should consider its benefits and limitations so that best choices are made.

As detailed above a sound understanding of the constraints affecting a Real-Time Operating System need to be categorised into hard, firm and soft constraints. If the system doesn’t have any hard time constraints then a contemporary operating system might be sufficient. If however there are hard or firm time constraints you will need a Real-Time Operating System.

References

Beal, V. (n.d.). What is an Operating System – OS? Webopedia Definition. [online] Webopedia.com. Available at: https://www.webopedia.com/TERM/O/operating_system.html [Accessed 12 Apr. 2018].

High Integrity Systems. (n.d.). What is an RTOS. [online] Available at: https://www.highintegritysystems.com/rtos/what-is-an-rtos/ [Accessed 10 Apr. 2018].

Ni.com. (2013). What is a Real-Time Operating System (RTOS)? – National Instruments. [online] Available at: http://www.ni.com/white-paper/3938/en/ [Accessed 12 Apr. 2018].

Thakur, D. (n.d.). Definition of Real Time Operating Systems. [online] Ecomputernotes.com. Available at: http://ecomputernotes.com/fundamental/disk-operating-system/real-time-operating-systems [Accessed 12 Apr. 2018].

Design News. (2016). Do You Need an RTOS? Yes, and Here Are 7 Reasons Why. [online] Available at: https://www.designnews.com/electronics-test/do-you-need-rtos-yes-and-here-are-7-reasons-why/29593780546421 [Accessed 24 Apr. 2018].

Freertos.org. (n.d.). Priority based preemptive RTOS scheduler. [online] Available at: https://www.freertos.org/implementation/a00005.html [Accessed 10 Apr. 2018].

Techterms.com. (n.d.). API (Application Program Interface) Definition. [online] Available at: https://techterms.com/definition/api [Accessed 11 Apr. 2018].

Micrium.com. (n.d.). Part 5: The Internet of Things and the RTOS | Micrium. [online] Available at: https://www.micrium.com/iot/iot-rtos/ [Accessed 11 Apr. 2018].

GeeksforGeeks. (n.d.). Operating System | Types of Operating Systems – GeeksforGeeks. [online] Available at: https://www.geeksforgeeks.org/operating-system-types-operating-systems-awaiting-author/ [Accessed 24 Apr. 2018].

Arthur, C. (2017). Difference in a RTOS And a GPOS? | Root Level Technology. [online] Root Level Technology. Available at: https://rootleveltech.com/difference-in-a-rtos-and-a-gpos/ [Accessed 24 Apr. 2018].

Dev.ti.com. (n.d.). General RTOS Concepts. [online] Available at: http://dev.ti.com/tirex/content/simplelink_academy_cc2640r2sdk_1_14_02_04/modules/rtos_concepts/rtos_concepts.html [Accessed 13 Apr. 2018].

www.tutorialspoint.com. (n.d.). Operating System Scheduling algorithms. [online] Available at: https://www.tutorialspoint.com/operating_system/os_process_scheduling_algorithms.htm [Accessed 13 Apr. 2018].

Percepio AB. (2016). RTOS 101: Semaphores and Queues – Percepio AB. [online] Available at: https://percepio.com/2016/08/11/rtos-101-semaphores-and-queues/ [Accessed 13 Apr. 2018].

Sawaal.com. (n.d.). What is a binary semaphore? What is its use? | Operating Systems Questions & Answers | Sawaal. [online] Available at: http://www.sawaal.com/operating-systems-question-and-answers/what-is-a-binary-semaphore-what-is-its-use_3377 [Accessed 23 Apr. 2018].

Rouse, M. (2018). What is logic gate (AND, OR, XOR, NOT, NAND, NOR and XNOR)? – Definition from WhatIs.com. [online] WhatIs.com. Available at: https://whatis.techtarget.com/definition/logic-gate-AND-OR-XOR-NOT-NAND-NOR-and-XNOR [Accessed 16 Apr. 2018].

Rouse, M. (2005). What is mutex (mutual exclusion object)? – Definition from WhatIs.com. [online] SearchNetworking. Available at: https://searchnetworking.techtarget.com/definition/mutex [Accessed 16 Apr. 2018].

Techopedia.com. (n.d.). What is a Lock (in Computing)? – Definition from Techopedia. [online] Available at: https://www.techopedia.com/definition/1841/lock [Accessed 18 Apr. 2018].

electric equipment. (2016). REAL-TIME OPERATING SYSTEMS:MEMORY MANAGEMENT. [online] Available at: http://machineryequipmentonline.com/electric-equipment/real-time-operating-systemsmemory-management/ [Accessed 17 Apr. 2018].

Techopedia.com. (n.d.). What is Real-Time Computing (RTC)? – Definition from Techopedia. [online] Available at: https://www.techopedia.com/definition/16991/real-time-computing-rtc [Accessed 25 Apr. 2018].

Jcsites.juniata.edu. (2017). Real-time Issues. [online] Available at: http://jcsites.juniata.edu/faculty/rhodes/smui/realtime.htm [Accessed 25 Apr. 2018].

B, P. and profile, V. (2014). Design philosophies for an RTOS. [online] Prabhakar-pkr.blogspot.co.uk. Available at: http://prabhakar-pkr.blogspot.co.uk/2014/07/design-philosophies-for-rtos.html [Accessed 25 Apr. 2018].

Freertos.org. (n.d.). FreeRTOS – Memory management options for the FreeRTOS small footprint, professional grade, real time kernel (scheduler). [online] Available at: https://www.freertos.org/a00111.html [Accessed 25 Apr. 2018].

Walls, C. (2016). Software in cars. [online] Embedded. Available at: https://www.embedded.com/design/operating-systems/4442406/Software-in-cars [Accessed 25 Apr. 2018].

Research Gate. (2008). Development of a Real-time OS Based Control System for Laparoscopic Surgery Robot. [online] Available at: https://www.researchgate.net/publication/263362664_Development_of_a_Real-time_OS_Based_Control_System_for_Laparoscopic_Surgery_Robot [Accessed 25 Apr. 2018].

Vitáris, B. (2017). R3 Aims to Build the ‘Operating System of Finance’. [online] CCN. Available at: https://www.ccn.com/r3-aims-build-operating-system-finance/ [Accessed 25 Apr. 2018].